1. Field of the Invention
The present invention relates to the fields of data processing. More specifically, the present invention relates to the provision of user interfaces.
2. Background Information
With advances in integrated circuit, microprocessor, networking and communication technologies, increasing number of devices, in particular, digital computing devices, are being networked together (wirelessly or via wire lines). As a result of this trend of increased connectivity, increasing number of client/server based and network dependent applications are being deployed. Examples of these client/server based and network dependent applications include but are not limited to, email, net based telephony, world wide web and various types of e-commerce.
Among the client/server based and network dependent applications, thin-client architecture, also known as web-client architecture, perhaps because of its “ease of implementation” on the client side, is especially popular. Typically, the architecture merely involves a “user-agent”, such as a Web browser or a WAP (Wireless Access Protocol) Browser, on the client side. There is no need for the client to have any application specific programs installed. Application specific logics are run on the server side, and the client just has to run the “user-agent” to render the user interface (where each instantiation is often referred as a “page” or a “web page”). The “user-agent” retrieves, for each instantiation of a user interface, a set of descriptions for the particular instantiation from the server, and renders the instantiation on a display screen as specified by the retrieved descriptions. The retrievals are made in response to a user's interaction with a current instantiation of the user interface, such as clicking a hyperlink or filling a form. The retrievals to be made are specified (as part of the descriptions) for the “user-agent” for each potential interaction, without requiring the “user-agent” to make any determination. The descriptions (including subsequent retrieval specifications) are typically authored in a “user-agent” specific language, such as HTML (Hypertext Markup Language) for Web browser, HDML/WML (Handheld Device Markup Language or Wireless Markup Language) for WAP browser.
Although this thin-client architecture allows the application programmers to implement a variety of applications, user experiences are generally poorer than user experiences with other conventional rich client applications (such as Office available from Microsoft of Redmond, Wash.). One of the reasons is because of the latency involved in the real time retrieval of each next set of definitions across the network. The user often has to wait while the retrieval is being made under the confine of limited networking/communication as well as server bandwidths, which may take upwards of seconds or more. This problem is often referred to as the “user interface latency” problem.
To solve this problem, “scripts” were introduced for HTML and WAP browsers. Script enabled “user-agents” allow authors of thin-client applications to embed some programs (a series of executable instructions) described in scripting-language (such as JavaScript or WMLScript), which give instructions to the “user-agents” on how to handle the user's input, without necessarily having to access the server, and retrieve the next set of user interface descriptions.
Although “scripting” was a sufficient solution for a certain set of user interactions (such as verifying that the user filled a certain field before submitting that data to the server), it significantly added the complexity to the development of thin client applications. Scripting is also not suitable when complex computations are required (such as determining the response to a user's move in a chess game), because of the limited resources on the client devices as well as the limitation of the script language itself.
HDML (and its successor, WML) introduced the concept of “cards and decks”, which allows the “user-agent” to retrieve multiple sets of user interface descriptions in a single round-trip. Each card describes a single unit of interaction including information to be presented to the user, and instructions for user inputs. A user essentially interacts or navigates through a series of cards. Multiple cards may be organized into a deck, which is equivalent to an HTML page. Although it reduces the number of round-trips in a certain set of scenarios, because it requires one card for each possible set of user interactions, it is not possible to apply this technology when the possible number of units of interactions is large or near infinite, as the number of user interface descriptions and their corresponding contents retrieved are large or near infinite. For example, if a user interface has 100 possible sets of user interactions, the descriptions of 100 cards must be retrieved in one round-trip or these descriptions must be separated into multiple decks and retrieved separately. Thus, the user still experience delays either due to the large amount of data to be transmitted in a single round trip or having to make multiple round trips.
Thus, what is needed is a new approach to provisioning user interface, that is more powerful in addressing large possible responses by the user, and allowing the solution to be client based (thereby eliminating the latency), but without the limitations and disadvantages of the prior art.